2023/05/23 更新: 為了避免本文章散落在不同網站,之後統一由部落格更新,再麻煩從部落格查看~
本文章同時發佈於:
文章為自己的經驗與夥伴整理的內容,設計沒有標準答案,如有可以改進的地方,請告訴我,我會盡我所能的修改,謝謝大家~
大家好,繼昨天DAY08的介紹後,Clean Architecture 架構告一段落。現在我們來思考一下,如果後端微服務龐大起來,如下圖,可能會產生什麼問題?
圖片來源: 微服務架構之「 下一代微服務 Service Mesh 」
雖然我們已經透過了 Swagger 最大程度的控管 Restful API 的介面,但值透過enum來實現
、這個參數是require但你忘記帶程式也不會告知你
,為了解決這些問題,有個很簡單粗暴的方法:
讓 Service 的溝通變成 function call 吧!
而這件事可以透過RPC(Remote Procedure Call)達成,流程圖如下,其實他得概念並不複雜,單純就是把call function與return result間的流程加了一道網路轉換
此圖來源: Day 16 - 分散式系統溝通的方法 - RPC
事實上 RPC 在 1976 年就誕生了,並不是什麼新技術,當時為了要處理多台電腦的通信採用此方法,後來衍伸出了XML-RPC、SOAP這樣的協定,但在定義與使用上都有些繁瑣古老,後來 Google 發展出了gRPC,為現代的微服務提供簡單高效強大的 RPC 協定。
二進制
的格式,以支援二進制溝通功能的HTTP/2來傳送,使得溝通極小極快。以 Golang 來說,這些定好的 Protobuf schema 透過官方的codegen tool,直接產生實際的 function 與 struct。
而你實際使用時,只要直接 call 此 function 並且帶對參數就可以了,因為是 function call,所以要帶什麼參數更加的直觀,而編譯器會告訴你是否帶對參數也更佳安全。
gRPC 在定義 function 時,可以針對不同場景,使用多種方案:
一個 request
訂閱 server 後,server 就可以發送無數次 response
。微服務很大的痛就是網路,試想看看 function call 有可能會因為網路不穩而失敗,這會多難麻煩 XD。
gRPC 可用此方法處理,Deadlines/Timeouts 來設定 timeout,go-grpc-middleware來 retry。
總而言之這是個要特別注意的地方,雖然變成了 function call 但他還是網路傳輸
XD。
接下來將介紹 gRPC 的傳輸方案的實際實作,謝謝你的閱讀~